\chapter{Entwurf der NOP-Engine}\label{chapter:design}
\input{chapters/design/ft}

\section{Vorbereitung zum Softwareentwurf}
"`Beim {\bf Softwareentwurf} handelt es sich um eine Phase im Projektzyklus, in der mit
vorliegender Problemdefinition eine technisch ad"aquate L"osung gesucht, analysiert und dokumentiert wird"' \cite{Schulz90}. In dieser Phase wird das Gesamtsystem in Teilsysteme auf Basis der Anforderungsspezifikation zerlegt \cite{Schontaler90}, die vollst"andig mittels Hardware oder Softwarel"osungen realisiert werden sollen. Dabei wird eine neue Technologie zur Zerlegung eines Gesamtsystems entwickelt, d.h. Schichtenarchitektur (engl. {\em layered archtecture}) \cite{Masak05}. Damit wird ein einzelnes System in so genannte Schichten aufgebaut, die jeweils  einige Verantwortlichkeiten haben, und zur Erf"ullung der Anforderungen und Entkoppelung der Teilsystemen dienen.
%Jedem Teilsystem wird ein relevanter Ausschnitt der Anforderungsspezifikation zugeordnet. F"ur alle durch Software zu realisierenden Teilsysteme wird dann ein Softwareentwurf durchgef"uhrt.
\subsection{Aufgaben des Softwareentwurfs}
In dieser Phase sollen die folgende Aufgaben zum Aufbau eines Systems erf"ullt :
\begin{itemize}
	\item Entwerfen einer Architektur f"ur das Gesamtsystem
	\item Beschreiben der Beziehungen zwischen den Systemkomponenten
	\item Spezifizieren des Funktions- und Leistungsumfangs sowie das Verhalten der
Systemkomponenten
	\item Festlegen der Schnittstellen
\end{itemize}
Die Ziele sind die Gestaltung des Softwaresystems, so dass die Anforderungen m"oglichst gut
erf"ullt werden.
%\subsection{Kategorisieren von Softwareentwurf}
%Mit den modernen Entwicklungstechnologien werden der Softwareentwurf weiter in zwei Teilbreiche,  Architekturentwurf und Implementierungsentwurf,  gespaltet. Beim Architekturentwurf handelt es sich um eine Verteilung von Objekten bzw. Anbindung der Objekten an die Systemsschnittstellen. Andererseits dient eine Implementierungsentwurf zur Verfeinerung des Architekturentwurfs und Anpassung an die gew"unschte Zielprogrammiersprache.
%Dabei werden die spezifische Programmierungssprache erst mal zum Einsatz gekommen sein.
\subsection{Modellierung eines Systems mit "`Domain-Driven Design"'}\label{section:ddd}
Bei {\bf "`Domain Driven Design"'} \ab{DDD} handelt es sich um ein Entwurfsmittel, damit versucht wird, die Sprache der jeweiligen Fachdom"ane objektorientiert abzubilden, um den Bruch zwischen fachlicher und technischer Beschreibung/Umsetztung m"oglischst gering zu halten \cite{Lieb07}. Es dient zur Modellierung eines Systems zum Bringen der Dom"anenprobleme in L"osung. In dem Buch \cite{Evans04} von Eric Evans werden eine Reihe von Konzepten artikuliert, die f"ur diese Modellierung zur Verf"ugugn gestellt werden.
\subsubsection{Entit"aten}
Bei {\bf Entit"aten} \engl{Entities} oder Referenz-Objekten \engl{Reference Object} \cite{Fow03} liegt die Betonnung auf Objekte, die "uber eine definierte, innerhalb der Anwendungsdom"anen nicht ver"anderbare Identit"at verf"ugen. Sie sind meisten persistent und werden in Datenbank gespeichert. 
\subsubsection{Wert-Objekte}
{\bf Wert-Objekte} \engl{Value objects} sind Objekte, die die Merkmale oder das Status eines anderen Objektes. Sie verf"ugen "uber keine eigene Identit"at Sie sind typischerweise unver"anderbar und als "`Flyweight design pattern"' \cite{Gamma94} angewendet.
\subsubsection{Services}    
{\bf Services} sind \kc{Operationen}, die f"ur keine Entit"at und keines Wert-Objekt geeignet. Services beschreiben normalerweise Verhalten von Systemen. Die meiste Funktionalit"aten eines Systems, die mehrere Dom"anenobjekte verwenden, K"onne  als Services dargestellt werden. 

\subsubsection{Aggregate}
Bei {\bf Aggregaten} \engl{Aggregates} handelt es sich um Entit"aten, die andere Entit"aten oder Wert-Objekte ale ein Teil an sich enthalten. Ein Aggregat beschreibt eine Hierarchie der Abh"angigkeiten der Entit"aten. Es ist sinnvoll, Aggregate aus Dom"anenobjekten herauszufinden, um die Eigenschaften dieser Hierarchie beim Manipulieren der Entit"aten nicht zu verletzen. Besonders zum Erkennen der Beziehungen zwischen Entit"aten, sowie "`one to one"', "`one to many"', "`many to one"' bzw "`many to many"' spielen Aggregate eine gro"se Rolle. 

\subsubsection{Repository}
Bei {\bf Repositorien} \engl{Repositories} handelt es sich darum, Objekte in seinem Lifecycle zu verwalten. Ein Repository wird als eine Liste betrachtet und als ein Interface deklariert. Damit kann man die Persistenzschicht verstecken und die Entit"aten durch Mock-Objekte\footnote{Die Definition Mock-Objekte wird im Kapitel \ref{chapter:test}, Abschnitt \ref{section:mo} erl"auert.} der Repositorien ohne Datenbank manipulieren. Es ist besonders sinnvoll,  die Gesch"aftslogik ohne Datenbank  zu implementieren und ihre Korrektheit parallel zu testen. 

\subsubsection{Fabrik}
Eine {\bf Fabrik} \engl{Factory} dient dazu, die Komplexe Objekte anzulegen, besonders die Wurzel-Entit"at eines Aggregats.
%\subsubsection{Modul}
%Beim {\bf Modul} handelt es sich um eine Menge von Anwendungsf"allen oder einen Teil der Anforderungen.
\\\\
Mit diesen wesentlichen Konzepten von DDD l"asst sich das Dom"anenmodell f"ur ein System leicht aufbauen. DDD ist besonders geeignet f"ur die objektorientierte \ab{OO} Programmierungssprachen, um eine OO-L"osung f"ur ein bestimmtes Problem anzubieten. Ausgehend von der Anforderungen soll die NOP-Engine in {\em Java}\footnote{Java ist eine objektorientierte Programmiersprache.} implementiert werden. Wir benutzen DDD als Hilfsmittel zum Aufbau einer f"ur {\em Java} geeigneten Architektur f"ur das System NOP-Engine. In den Reste dieses Kapitels wird angezeigt, wie ein Dom"anenmodell f"ur das System NOP-Engine mit Hilfe von DDD erstellt wird.% und der dynamische Einsatz mehrerer Funktionen f"ur den Parameter $f$ in L"osung gebracht werden.

\subsection{Graphische Modellierung mit UML}
Die {\bf Vereinheitlichte Modellierungssprache} ({engl. {\em Unified Model Language}, kurz. {\em UML}}) ist eine Menge von graphischen Notationen, die von einem Einzelnen Meta-Modell unterst"utzt werden, um ein System beschreiben und entwerfen zu helfen, Besonders die Systeme, die objektorientiert entworfen und implementiert werden (sollen) \cite{Fow03}. Als das Standard der Modellierungssprachen ist die UML breit in der Softwareentwicklungswelt angewendet. Die Einheit zum Beschreiben eine Aspekt eines Systems in UML ist  ein {\bf Diagramm}, das aus einer Reihe von den vordefinierten graphischen Notationen besteht und die vollst"andige Bedeutung einer Aspekt eines Systems erz"ahlt. Die aktuelle Version der UML ist 2.0. Daf"ur stehen insgesamt 13 Diagramme zur Verf"ugung. In der vorliegenden Arbeit werden die Anwendungsfall- \engl{use case}, Aktivit"ats- \engl{activity}, Sequenz- \engl{sequence}, Klassen- \engl{class}, Verteilungs- \engl{deployment} und Packetdiagramm \engl{package diagram} als ein Hilfsmittel zur Modellierung der NOP-Engine angewendet, um auf die unterschiedlichen Aspekte der NOP-Engine anschaulich darzustellen.

\section{Architektur der NOP-Engine}
Zum Entwerfen der NOP-Engine  wird das {\bf Schichtenarchitektur mit der isolierten Dom"anenschicht} \engl{layered architecture with the isolated domain layer} verwendet, das im Buch \cite{Evans04} von Eric Evans vorgestellt wird. Eine isolierte Dom"anenschicht enth"alt die Objekte, die die Gesch"aftslogik eines System zu implementiert und die funktionalen Anforderungen dieses Systems erf"ullt. Sie soll durch die im Abschnitt \ref{section:ddd} erw"ahnten Konzepten von DDD bzw. die UML-Diagramme zum Einfachen der Implementierung modelliert werden. Im Abschnitt \ref{section:dddmodel} wird diese Modellierung detailliert beschrieben.
%\subsection{Schichtenarchitektur mit der isolierten Dom"anenschicht}
\subsection{Vier Schichten der Architektur}
Die Gesamtarchitektur gliedert sich in 4 unterschiedliche Schichten mit verschiedenen Verantwortungsbereichen.
\begin{itemize}
	\item Pr"asentationsschicht 
	\item Applikationsschicht 
	\item Dom"anenschicht 
	\item Infrastruktur-Schicht 
\end{itemize}
Bei der Pr"asentationsschicht behandelt es sich um die Informationsanzeige f"ur den Benutzer, Interpretation der Benutzerkommandos. Applikationsschicht ist eine schlanker schicht ohne Gesch"aftslogik, und bescheibt bzw. koordiniert die Gesch"aftsprozesse und die Arbeit an Kollaborationen im darunter liegenden Schichten. Bei der Dom"anenschicht liegt die Betonnung darauf, die Konzepte der jeweiligen Problemdom"ane zu repr"asentieren. Sie ist die wichtigste Schicht, die die Hauptaufgaben einer Software zur l"osung bringen soll. Die Infrastruktur-Schicht befasst sich mit allgemeinen, technischen Services zur Unterst"utzung der dar"uberliegenden Schichten.
\subsection{Vorteile der Schichtenarchitektur}
Innerhalb der einzelnen Schicht kann einer starken Koh"ansion untergelegen werden. Zwischen einzelnen Schichten wird eine Entkopplung angestrebt. Es gilt, dass nur "ubergeordnete Schichte von den darunter liegenden abh"angig sein d"urfen, und nicht umgekehrt werden. Zur Komunikation zwischen einzelne Schichten sollen "uber eine Indirektion erfolgen, um Abh"angigkeiten zu minimieren, in anderen Worten, gegen Interfaces, und nicht gegen konkrete Klassen zu implementieren.
%\subsection{Zerlegen des NOP-Engine in Teilsysteme zur Anpassung der Architektur}
%Ausgehend von der Definition vom Softwareentwurf wird das System NOP-Engine in 4 Teilsysteme mit eigenem Namen und den Verantwortlichkeiten zerlegt, so wie in der Tabelle \ref{table:subsystem} dargestallt.\\
\subsection{Einsatz der Schichtenarchitektur in der NOP-Engine}
Zum Entwerfen der NOP-Engine ist die Schichtenarchitektur mit der isolierten Dom"anenschicht im Einsatz gekommen. In der Tabelle \ref{table:subsystem} werden diese vier Schichten und ihre Verantwortlichkeiten dargestellt. In dem System NOP-Engine dient die Infrastruktur-Schicht nur zur Verbindung der Datenbank und zum Speichern bzw. Wiederfinden der Objekte. Um diese Funktionalit"at besser zu verstehen wird diese Schicht im Rest dieser Arbeit als Persistenzschicht genannt.\\
\TableSubsystems\\
Im Folgenden wird angezeigt, wie das System NOP-Engine mit dieser Schichtenarchitektur durch DDD und mehrere Entwurfsmuster auf  der Entwurfsebene aufgebaut wird.
%Mit den Verantwortlichkeiten werden auch die Abh"angigkeiten zwischen die Teilsysteme angezeigt. Hierbei wird ein Komponentendiagramm (\warn{siehe die Abbildung}) zur Beschreibung dieser Abh"angigkeiten dargestellt.\\\\
%Diese vier Teilsysteme und die vier Schichte der vonobenerw"ahnten Architektur passt zusammen. Jedes einzelnes Teilsystem ist nur abh"angig von den unterliegenden Teilsystemen. So wie in der Abbildung dargestellt, werden die Teilsysteme in den Architektur-Schichten eingepackt. Dabei werden auch die "Abhangigkeiten angezeigt.\\\\


%------------------------------------------------------------------------------------------

\section{Modellierung der Objekten der Dom"anenschicht}\label{section:dddmodel}
Die Aufgabe der Dom"anenschicht ist die Gesch"atslogik der NOP-Engine zu implementieren und ihre funktionalen Anforderungen zu erf"ullen. Im Folgenden wird diese Aufgabe durch ein Dom"anenmodell mit Hilfe von DDD und den UML-Diagrammen in L"osung gebracht.
%Im Teilsystem\threemodul sollen die meiste Anforderungen einschlie"slich der Gesch"aftslogik vom NOP-Engine erf"ullt werden. Es ist die wichtigste aller 4 Teilsystemen. Im Folgenden wird mit Hilfe von DDD bzw den UML-Diagrammen dieses Teilsystem modelliert.


\subsection{"Ubersetzung der funktionalen Anforderungen in Schnittstellen}
Alle funktionalen Anforderungen\footnote{Die Anforderungen, etwas anzuzeigen, geh"oren nich dazu.} der NOP-Engine sollen in Schnittstellen "ubersetzt und miteinander, so wie in der Tabelle \ref{table:neinterface} dargestellt, abgebildet werden.\\
\TableNEInterface\\
Anhand der Abh"angigkeit sollen diese Schnittstellen von der Applikation- und Pr"asentationsschicht verwendet werden. Wir stellen ein Interface {\em INopEngine}, die alle obengenannte Schnittstellen enth"alt, daf"ur zur Verf"ugung. 

\subsection{Umwandlung der Konzepte der NOP-Engine in Dom"anenobjekten}
Alle Konzepte, die bisher aufgetaucht sind, f"ur die NOP-Engine zum Berechnen von NOPs sollen als Dom"anenobjekte durch DDD umgewandelt werden.
\subsubsection{Entit"aten}
\begin{itemize}
	\item Die Konzepte, die f"ur das Gugubarra-System global definiert werden sollen, sind die Entit"aten, da sie von allen Teilsystemen vom Gugubarra verwendet werden und persistent sein sollen. Die Konzepte Thema, Aktion und Benutzer geh"oren zu dieser Gruppe.
	\item Alle Konzepte, die mindestens in zwei Teilsystemen\footnote{Die Systeme NOP-Engine, Designer und Clustering sind die Teilsysteme des Gugubarra-Systems.}  des Gugubarra-Systems im Einsatz gekommen sind, werden in Entit"aten umgewandelt, sowie Zone, Thema-Gewicht einer Zone, NOP, Thema-Gewicht eines NOPs, Benutzer-Session, Zeitdauerhandlungsweise bzw. Aktionshandlungsweise. Weil eine Synchronisation f"ur je zwei Teilsysteme unverbindlich ist. 
	%\item Die notierte wohlgeformte Handlungsweisen bzw. ihre Zeitdauerinformationen und Aktionsinformationen sollen als Entit"aten betrachtet, weil sie die Ergebnisse vom Designer und die Eingaben vom NOP-Engine sind, und mit verschiedenen Strategien wiederverwendet werden.
	\item Die Konzepte, die zum Berechnen von NOPs immer wiederverwendet werden, sollen auch als Entit"aten betrachtet werden. Sie sind NOP-Projekt, Strategie und Semantik.
\end{itemize}
Ausgehend von der Definition der Entit"at soll jedes obenerw"ahntes Objekt au"ser ihren Eigenschaften noch "uber einen Schl"ussel {\em id} (Objekt-ID) verf"ugen.
\subsubsection{Wert-Objekte}
\begin{itemize}
	\item Der Zonenzustand soll in Wert-Objekten umgewandelt werden, da er den Status einer Zone beschreibt.
	\item Eine Seitenregel bezeichnet eine Eigenschaft einer Strategie und ist selbst unver"anderbar, d.h. sie soll auch als ein Wert-Objekt betrachtet.
\end{itemize}
Wir geben einen Namen f"ur jedes herausgefundenes Objekt, so wie in der Tabelle dargestellt.\\
\TableObjects


\subsubsection{Aggregate}\label{section:aggregate}
In der Abbildung \ref{figure:classes} steht ein Klassendiagramm, das alle Entit"aten und Wert-Objekte der NOP-Engine bzw. ihre Abh"angigkeiten anschaulich dargestellt. Ausgehend von der Anforderungen sollen drei Objekte , sowie {\em Nop}, {\em UserSession} und {\em NopProject} direkt von der NOP-Engine zugreifen k"onnen. Aus diesem Klassendiagramm werden die Aggregate f"ur diese drei Objekte leicht herausgefunden. Die wichtigen Beziehungen sehen wie folgenden aus,
\begin{itemize}
\item {\em Nop} und {\em NopProject}: "`one to one"'
\item {\em Nop} und {\em TopicNopWeight} bzw. {\em Topic}: "`many to many"'
\item {\em NopProject} und {\em Strategy}: "`one to one"'
\item {\em UserSession} und {\em DurationInfo} bzw. {\em ActionInfo}: "`one to many"'
\item {\em DurationInfo} und {\em Zone}: "`many to many"'
\item {\em Zone} und {\em TopicZoneWeight} bzw. {\em Topic}: "`many to many"'
\item {\em ActionInfo} und {\em Action}: "`many to one"'
\end{itemize}
Diese Beziehungen stehen f"ur das Aufbauen der Datenbanktabellen und das O/R-Mapping der Entit"aten mit diesen Tabellen zur Verf"ugung. Im Kapitel \ref{chapter:impl}, Abschnitt \ref{section:usehi} wird angezeigt, wie die Entit"aten und ihre entsprechenden Datenbanktabellen durch diese Beziehungen mit {\em Hibernate} abgebildet werden k"onnen.
\FigureClasses
%Aus allen Entit"aten und Wert-Objekten werden drei Aggregate herausgefunden, die die Hierarchien von Zonen, NOPs, und Benutzer-Sessionen beschreiben. 
%\begin{itemize}
	%\item Die Hierarchien f"ur die Benutzer-Session ($UserSession$) und das NOP-Projekt ($nopProject)$ sind ziemlich komplex und daf"ur wird ein Aggregat zur Verf"ugung gestellt, um diese Hierarchie zu verdeutlichen.
	%\item Die Abh"angigkeiten zwischen $Nop$ und anderen Entit"aten sollen auch als ein Aggregat dargestellt.
%\end{itemize}
%Hierbei wird ein , um einen anschaulichen Eindruck von den herausgefundenen Objekten bzw. Aggregaten zu haben.
\subsubsection{Services}
Die Start-Funktion und drei Subroutinen des Kern-Algorithmus\footnote{Die Start-Funktion und drei Subroutinen werden im Kapitel \ref{chapter:algo}, Abschnitt \ref{section:algo} erl"autert}, die zum Berechnen von NOPs beitragen k"onnen, sollen als vier Services betrachtet werden.
\paragraph{Die Start-Funktion {\em calculateNops}:} F"ur diese Start-Funktion steht das Service {\em ICalculateNops} zur Verf"ugung, das als ein Java-Interface dargestellt wird, und "uber die Schnittstelle {\em calculateNops} verf"ugt, die f"ur die Berechnung von NOPs aller Benutzer mit einem eingegeben NOP-Projekt zust"andig ist.
\paragraph{Die Subroutine {\em calculateNop}:} Die erste Subroutine erf"ullt die Aufgabe zur Berechnung  eines NOPs eines Benutzers in Bezug auf eine Benutzer-Session. Daf"ur wird das Service {\em ICalculateNop} (Interface) mit der Schnittstelle {\em calculateNop} erstellt.
\paragraph{Die Subroutine {\em DurP}:} das Service {\em ICalculateDurP} steht f"ur Die zweite Subroutine zur Verf"ugung. Mit der Schnittstelle dieses Services {\em calculateDurationProfile} soll die Zeitdauerprofil f"ur ein Thema berechnet werden.
\paragraph{Die Subroutine {\em ActP}:} Zur Erf"ullung der Aufgabe der dritten Subroutine wird das Service {\em ICalculateActP} mit der Schnittstelle {\em calculateActionProfile} erstellt. damit das Aktionsprofil in Bezug auf ein Thema berechnet wird.\\\\
In der Abbildung \ref{figure:sequenceNop} wird ein Sequenzdiagramm zur Beschreibung der Interaktionen zwischen den vier Services dargestellt.
\FigureSequenceNop
	%\item  Die andere Anforderungen in der Liste 1 sind nur  Entit"aten, NOP-Projekte und NOPs anzulegen oder abzuspeichern. Diese Aufgaben soll direkt durch einem Repository erf"ullt werden.
%\end{itemize}
\subsubsection{Repositorien}
F"ur die NOP-Engine wird nur ein Repository zur Verf"ugung gestellt, das als ein Java-Interface
{\em INopEngineRep} dargestellt. Dabei sollen alle Schnittstellen, die in der Tabelle \ref{table:neinterface} dargestellt werden und die Datenbanktabellen zugreifen k"onnen, im Interface \mbox{{\em INopEngineRep}} verpacket werden.

\subsubsection{Fabrik}
Zum Anlegen der komplexen Dom"anenobjekten, sowie {\em NopProjekt} und {\em Nop} wird eine Fabrik {\em NopFactory} als eine Java-Klasse erstellt, die "uber zwei Schnittstellen, {\em createProject} und {\em createNop} verf"ugt. Bei der Implementierung dieser Schnittstellen m"ussen auf die Aggregate f"ur beide Objekte aufgepasst werden.

\subsection{L"osung zum freien Ausw"ahlen einer konkrete Funktion f"ur den Parameter $f$}
Ausgehend von der speziellen Anforderungen sollen die Funktionen zur Auswertung des Parameters $f$ frei w"ahlbar sein. Zum l"osen dieses Problems wird ein Entwurfmuster "`strategy"' \cite{Gamma94} angewendet. Der Parameter $f$ ist eine Einstellungsvariable der NOP-Engine und soll durch die Strategie zugriffen  werden. Wir erstellen zun"achst ein Interface {\em ICalculateF}, das mit der Schnittstelle {\em getValue} den Parameter $f$ auswerten kann. Alle konkreten Funktionen zur Auswertung des Parameters $f$ sollen dieses Interface realiseren. Dann wird eine neue Eigenschaft \kc{paramfKey}mit dem Typ \kc{String}im Objekt {\em strategy} hinzugef"ugt. Es soll die Information zum Ausw"ahlen der Funtionen enthalten. Danach wird noch ein Interface \kc{IGetParamFFunc}dargestellt, das mit der Schnittstelle \kc{getFunc}durch die Zeichenketten \kc{paramfKey}die richtige Funktion herausfinden kann. Eine Strategie soll "uber eine Instanz einer Konkrete Realisierung vom \kc{IGetParamFFunc}verf"ugen, und durch die folgende Schritte den Wert vom Parameter $f$ zum Berechnen von NOPs anbieten.
\begin{enumerate}
	\item Herausfinden der richtige Funktion f"ur den Parameter $f$ durch das Attribut \kc{paramfKey}
	\item Berechnen des Werts von dem Parameter $f$ mit der herausgefundenen Funktion.
\end{enumerate}
Beide Interfaces sollen als Services betrachtet werden. Die Aufgabe zum Ausw"ahlen der Funktion wird von dem Service \kc{IGetParamFFunc}"ubergenommen. Dadurch wird die Information der Konkrete Funktion f"ur den Parameter $f$ versteckt. Das hei"st, die Auswertung des Parameters $f$ ist nicht von einer konkreten Funktion abh"angig, sondern wird durch die dynamisch geladene Funktion ausgef"uhrt. Diese L"osung wird als ein Klassendiagramm in der Abbildung \ref{figure:paramf} dargestellt. Im n"achsten Kapitel zeigen wir an, wie man mit der "`Java-Reflektion"' das Interface \kc{IGetParamFFunc}realisieren kann.
\FigureParamF\\\\
%Im n"achsten Kaptiel wird die korrekte Realisierung von \kc{IGetParamFFunc}durch das {\em reflection}-Mechanismus von \kc{Java} vorgestellt.
Bis Hierher wird ein Dom"anenmodell durch die Konzepte von DDD und die UML-Diagramme f"ur die NOP-Engine anhand der funktionalen Anforderungen dargestellt. Dabei werden alle zum Berechnen von NOPs ben"otigten Objekte f"ur die Implementierung zur Verf"ugung gestellt.
%----------------------------------------------------------------------
%----------------------------------------------------------------------
\section{Entwurf der Persistenzschicht}
In der obenerw"ahnten Schichtenarchitektur steht Persistenzschicht ganz unten. Mit anderen Worten darf sie von den Schnittstellen und Objekten der Dom"anenschicht nicht abh"angen.
\subsection{Schnittstellen der Persistenzschicht}
F"ur die Schnittstellen au"ser \kc{cauculateNops}vom "`NOP-Engine Kernel"' sollen zwei Basis-Operationen, \kc{save} und \kc{find} erstellt. Ausgehend von {\em Java} und {\em Hibernate} ist es M"oglich, die Anforderungen vom\threemodul durch das angebliche "`dynamische Binden"' mit \kc{Criteria} zu erf"ullen. Mit dem Interface {\em IPersistenceTool} werden beide Schnittstellen verpackt, und f"ur das\threemodul zur Verf"ugung gestellt.
\subsection{Strategie zum Aufbauen der Datenbanktabellen}
Zum Aufbauen der Datenbanktabellen wird eine Mapping-Strategie angewendet, die sogenannte "`eine Tabelle pro konkreter Klasse"' \cite{Starke02}. Der Vorteil dieser Strategie ist eine schnelle Durchf"uhrung der Anfragen. Wir erstellen f"ur jede Entit"at eine Tabelle, so wie in der Tabelle \ref{table:dbtables} dargestellt. Die letzte Tabelle pflegt die Beziehung zwischen den Objekten {\em DurationInfo} und {\em Zone}. Daf"ur ist ein zus"atzliches Objekt nicht erforderlich.\\
\TableDB
%\subsection{Erstellen der Beschr"ankungen der Datenbank-Tabellen durch die Aggregate}
%Mit Hilfe von den Aggregaten werden die Beschr"ankungen \engl{Constrains} der Datenbank-Tabellen festehalten.
%\subsection{Anpassen von Hibernate}
\subsection{L"osung zur Historisierung}
Die L"osung zur Historisierung von Aktionen und Zonen besteht drin, dass f"ur jede "Anderung ein neues Objekt erstellt werden soll. Dann werden zwei weiteren Eigenschaften in den Objekten {\em Action} und {\em Zone} hinzugef"ugt. F"ur das Objekt {\em Zone} sind {\em zone\_id} bzw. {\em version}, und f"ur {\em Action} {\em action\_id} bzw. {\em version}. Alle Zonen oder Aktionen mit der selben {\em zone\_id} bzw. {\em action\_id} aber unterschiedlichen {\em version} werden als eine Zone oder Aktion mit verschiedenen Versionen betrachtet. Diese Eigenschaften sind als einen Schl"usselkandidat vorgesehen. Damit kann man eine versionierte Zone oder Aktion durch diese Eigenschaften eindeutig bestimmen. Auf der Designer-Seite sollen diese Eigenschaften von Zonen und Aktionen in den notierten Handlungsweisen hinzugef"ugt, und danach auf der Seite der NOP-Engine durch diese Eigenschaften die richtigen Zonen und Aktionen wiedergefunden werden.\\\\
Zur Historisierung von NOP's wird eine andere L"osung in dieser Arbeit gegeben, da die Berechnung eines neuen NOP's nur von der aktuellen NOP's abh"angig ist, und die alte NOP's nicht mehr verwendet werden. In diesem Fall ist ein Versionierungsmechanismus nicht erforderlich. Dazu soll jedes NOP nur "uber eine weitere Eigenschaft {\em created} verf"ugen, die den Erzeugungszeitpunkt des NOP's darstellt. Damit kann das aktuelle NOP eines Benutzers in Bezug auf ein NOP-Projekt durch den gr"osten Erzeugungszeitpunkt herausgefunden werden.

\section{Entwurf der Applikationsschicht}
Die Applikationsschicht der NOP-Engine dient zum integrieren der Schnittstellen der Dom"anen- und Persistenzschicht, und bietet der Repr"asentationsschciht die Dom"anenobjekte an. Diese Aufgabe wird vom Applikationsframework {\em Spring} vollst"andig "ubergenommen.
%Das Interface {\em INopEngineServices} wird dazu angelegt, und verf"ugt "uber eine Instanz vom {\em INopEngine} und eine vom {\em IPersistenceTool}. 
Im n"achsten Kapitel wird angezeigt, wie diese Integration mit {\em Spring}  realisiert wird.
%---------------------------
%---------------------------
\section{Entwurf der Repr"asentationsschicht}
Ausgehend von der Anforderungen\footnote{Die Anforderungen, die etwas anzeigen, werden im Kapitel \ref{chapter:requirment}, Abschnitt \ref{section:funreq} erl"autert.} sind f"unf Web-Seiten von der NOP-Engine gefordert, sowie Start-Men"u, Projekt-Anzeiger, NOP-Anzeiger, Projekt-Editor, Nachricht-Anzeiger.
\subsection{Entwerfen der Web-Seiten}

\subsubsection{Start-Men"u}
Wir nennen die Web-Seite f"ur das Start-Men"u als {\em startMenu}. Ausgehend von den Anwendungsf"allen werden die folgende Anforderungen von dieser Web-Seite erf"ullt.
\begin{itemize}
	\item Selektieren eines NOP-Projekts
	\item Bestimmen, den Inhalt eines ausgew"alten NOP-Projekts anzuzeigen
	\item Berechnen von den NOPs eines ausgew"ahlten NOP-Projekts 
	\item Selektieren eines NOPs
	\item Bestimmen, den Inhalt eines ausgew"alten NOPs anzuzeigen
\end{itemize}

\subsubsection{Projekt-Editor}
Die Web-Seite f"ur den Projekt-Editor als {\em projectEditor} genannt. In dieser Web-Seite kann man die  Einstellungsvariablen f"ur die NOP-Engine und die Informationen f"ur das neue NOP-Projekt selbst (die aktualisierungsinformationen) eingeben und abspeichern.
%Jede Anforderung soll als eine Komponente von {\em JSF} in dieser Web-Seite dargestellt. Zum Bestimmen von dem Anzeigen eines NOP-Projekts bzw. eines NOPs  werden die Komponente \kc{commandLink} werwendet.
\subsubsection{Projekt-Anzeiger}
Der Projekt-Anzeiger wird als eine Web-Seite mit dem Namen {\em projectPane} dargestellt. Sie dient zum Anzeigen aller Einstellungsvariablen f"ur die NOP-Engine und die Informationen f"ur ein ausgew"ahltes NOP-Projekt.
\subsubsection{NOP-Anzeiger}
Diese Web-Seite wird als {\em nopPane} bezeichnet, und erf"ullt die Auggabe, den Inhalt eines ausgew"ahlten NOPs anzuzeigen.
\subsubsection{Nachricht-Anzeiger}
Der Nachricht-Anzeiger wird als {\em massageBox} genannt. Diese Web-Seite hat nur eine Aufgabe, alle Fehlermeldungen bzw. die Abschluss-Nachricht als Zeichenketten darzustellen.
\subsection{Front Controller}
Beim {\bf Front Controller} \cite{Crup03} handelt es sich um einen Entwurfsmuster, mit dem ein Kontroller aufgebaut wird, der den HTTP-Request f"ur alle Web-Seiten einer Applikation entgegennimmt und die Reponse steuert. In der Repr"asentationsschicht wird das Front Controller angewendet und als ein Objekt \kc{SystemContoller}dargestellt, das f"ur die Response aller Web-Seiten zur Verf"ugung stehen. Dies Objekt verf"ugnt "uber eine Instanz des Objekts, das das Interface {\em INopEngine} realisiert hat, um die Funktionalit"aten der Dom"anenobjekte verwenden zu k"onnen.
%--------------------------
%--------------------------
\section{Erstellen der Java-Paketen zur Verwaltung der Objekte}
Zu dem besseren Organisieren der herausgefundenen Objekte und der Anpassung dieser Objekten an die Schichtenarchitektur der NOP-Engine werden drei Java-Pakete zur Verf"ugung gestellt. 
\subsection{Das Paket {\em de.gugubarra.core.nop}}
Das Paket {\em de.gugubarra.core.nop} verpackt alle Objekte in der Dom"anenschicht. Auf der ersten Ebene stehen die Klassen aller Entit"aten und Wert-Objekten. Darunter liegen  drei weitere Pakete, die f"ur die Services, das Repository bzw. die Fabrik zur Verf"ugung stehen, und als 
\begin{itemize}
\item {\em de.gugubarra.core.nop.service}
\item {\em de.gugubarra.core.nop.repository}, bzw.
\item {\em de.gugubarra.core.nop.factory}
\end{itemize}
bezeichnet. Die funktionen zur Auswertung des Parameters $f$ stehen noch tiefer unten, und wird als {\em de.gugubarra.core.nop.service.funcf} genannt.
\subsection{Das Paket {\em de.gugubarra.persistence.nop}}
Die Persistenzschicht verf"ugt "uber ein eigenes Paket {\em de.gugubarra.persistence.nop}, in dem das Interface {\em IPersistenceTool} und dessen Korrekte Realisierung stehen.

\subsection{Das Paket {\em de.gugubarra.ui.nop}}
F"ur die Repr"asentationsschicht wird das Paket {\em de.gugubarra.ui.nop} zur Verf"ugung gestellt, das "uber alle Objekte zum Aufbauen der Web-Seiten verf"ugt. Der Front Controller \kc{SystemController} geh"ort auch zu diesem Paket.\\\\
Wegen der Anwendung des Frameworks {\em Spring} wird kein zus"atzliches Paket f"ur die Applikationsschicht zur Verf"ugung gestellt. {\em Spring} "ubernimmt die Aufgabe dieser Schicht, und ist direkt f"ur das Gesamtsystem im Einsatz gekommen.\\\\
In der Abbildung \ref{figure:package} wird ein Paketdiagramm dargestellt, um einen anschaulichen Einblick f"ur diese Pakete bzw. die Schichtarchitektur der NOP-Engine zu haben.
\FigurePackage
\section{Zusammenfassung}
In diesem Kapitel wird einen Softwareentwurf durchgef"uhrt. Dabei wird das System NOP-Engine in einer Schichtenarchitektur auf der Entwurfsebene aufgebaut, und mit Hilfe der Konzepten von DDD und der UML-Diagrammen modelliert. Im folgenden Kapitel werden detailliert beschrieben, wie dieser Entwurf durch die Java-Technologien sowie {\em JSF}, {\em Hibernate} und {\em spring} implementiert werden.





%Ausgehend von der Aufgabenstellung sollen nur wesentliche Elemente zum Berechnen von NOPs als die Web-Seiten dargestellt werden.